1. Field of the Invention
The present invention relates generally to a computerized authentication system and process that utilize public key cryptography, and more specifically, to such a system and method that are able to re-establish authentication system security after compromise of same.
2. Brief Description of Related Prior Art
In a distributed data processing network system, a methodology employed to reliably verify the identity of a communicating device on the network prior to allowing the device to access system operations and resources is referred to as authentication. Access to the system may be, for example, for the purpose of communicating with other users, retrieving secure information, or receiving a service. Distributed systems generally include various computer nodes interconnected by a communications medium. The computer nodes may include nodes that are directly accessed by users, e.g., workstations, and nodes running specialized applications, e.g., servers. These nodes, the processes running on these nodes, and the users of the distributed system are referred to as "principals." The authentication exchange is performed on behalf of the principals.
Public key cryptography is a method of secure communication in which each principal has a public encryption key and a private encryption key. An encryption key is a code or number which, when taken together with an encryption algorithm, defines a unique transformation that is used to encrypt or decrypt data. A public key system may be used in such a way as to ensure confidentiality of the information being transmitted, i.e., to ensure that the information may not be understood by an eavesdropper, as well as to ensure the authenticity of the sender of the information.
The manner in which a public key cryptography system operates to ensure authentication may be understood without reference to the mathematical transformations that are used for encryption and decryption. Public key cryptography is also referred to as "asymmetric" encryption because information encoded with a public key may be decoded only by using an associated private key and vice versa, the associated private and public keys defining a private/public key pair. According to this type of encryption, the private key is known only to the owner of the key, while the public key is known to other principals in the system.
Accordingly, to effect a secure transmission of information to a recipient, a principal encodes ("encrypts") the information with the recipient's public key. Since only the intended recipient has the complementary private key, only that principal can decode ("decrypt") it. On the other hand, to prove to a recipient of information that the sender is who he purports to be, the sender encodes ("signs") the information with its private key. If the recipient can decode ("verify") the information using the sender's public key, it knows that the sender has correctly identified itself. In public key cryptography, each principal is responsible for knowing its own private key and all the public keys are generally kept in a convenient location, typically a directory service (DS). Alternatively, each principal may store its own public key, furnishing it to a recipient during an authentication exchange.
It is essential to reliably know which public key belongs to which principal. The typical solution for this problem is to use a trusted entity known as a certificate authority (CA). A CA generates identity certificates, which are signed messages specifying a "subject," i.e., the name of the principal whose public key is being certified, the certificate serial number, name of the CA issuing the certificate, the subject's public key, and also, typically, a certificate expiration date. This verification of the relationship between the public key and the principal to which it belongs precludes an intruder from compromising the system by posing as a valid principal. Since each certificate is signed by the private key of the CA to ensure the authenticity of the certificate itself, all principals in the network that are required to authenticate a principal must somehow securely learn the CA's public key so that they can verify its signature on the certificates. Certificates may be stored in any convenient location, such as a DS, or each node can store its own certificate and furnish it as part of the authentication exchange. Typically, in order to provide enhanced security, the CA is an off-line entity and communicates to network principals via secure off-line communications techniques.
For complete network security, every principal must have a certificate. Sometimes, however, it is desirable to later disable a certificate after it has been issued but prior to its expiration. For example, a principal's private key may be stolen, compromised or lost, etc. Under such circumstances, it is desirable to revoke the certificate, thereby disabling authentication via that certificate.
Various schemes have been developed to revoke unexpired certificates. In one conventional approach, all valid principal certificates are stored on-line in some location, such as a DS, and are publicly available for retrieval. For example, when a user needs to authenticate to a server, the server polls the DS to see if the user's certificate is present in the DS. If a user's certificate is not stored in the DS, then it is concluded that the certificate has been revoked.
Another conventional approach is to issue a list from the CA of unexpired certificates that should not be honored, referred to as a Certificate Revocation List (CRL). The Certificate Revocation List may have a format defined by the ITU-T Recommendation X.509, formally referred to as the ISO/IEC 9495-8: Information Technology-Open Systems Interconnection-The Directory-Authentication Framework, 1988 (revised 1993). An application considers a certificate as valid if it has not expired and is not listed in the CA's current CRL. Unfortunately, since a CRL can become quite large over time (i.e., as an ever greater number of certificates are revoked and added to the CRL), it can consume a large amount of network bandwidth, storage space, and CA processing power to distribute the CRL to all network nodes desiring the information contained in the CRL. Due to the difficulty involved in obtaining a CRL, this means that the CRL will typically not be compiled frequently, thus the CRL may be out of date.
One conventional approach to solving this problem involves use of an on-line revocation server (OLRS). The OLRS maintains a database of certificate revocation status information that may include, for instance, information derived from the version of CA's CRL that was most recently provided to it, and real-time information that it receives via secure channels that other unexpired certificates issued by the CA have been revoked. The OLRS makes its certificate revocation information available on-line to network principals that may ask the OLRS for it. That is, network principals may make on-line queries to the OLRS for certificate revocation information, and the OLRS provides responses to such queries based upon the OLRS' certificate revocation status information. Because the OLRS responds to specific on-line queries, its responses can be more timely than information provided by the off-line CA and be more efficient because it includes only the information requested.
Unfortunately, the relatively greater access to the OLRS provided by the fact that it is an on-line, and perhaps replicated entity (as opposed to the CA, which typically is off-line) inherently reduces OLRS security and increases likelihood of compromise of the OLRS (e.g., theft of the OLRS private key and/or unauthorized modification of the certificate revocation status information in the OLRS). Therefore, it is important that the OLRS have a different private key from the CA because the OLRS is more susceptible to compromise as a result of the OLRS being on-line; however, compromise of the OLRS private key is less of a security threat than compromise of the CA's private key, since compromise of the OLRS private key only means that previously revoked certificates may be indicated to inquiring principals as unrevoked or unrevoked certificates may be indicated to inquiring principals as revoked, whereas compromise of the CA's private key may result in unauthorized issuance of certificates.
Conventionally, the OLRS authenticates the certificate revocation status information provided by the OLRS as a result of queries by inquiring principals by signing the query results using the OLRS private key. The CA also certifies the authenticity of the OLRS's public key by providing a "delegation certificate" to the OLRS which is signed by the CA's private key and which contains information in addition to that in an ordinary certificate (e.g., identifying that this is an authorization to the specified OLRS from the CA to provide certificate revocation status information). The delegation certificate may be provided to verifying principals to verify that the OLRS is authorized to provide the certificate revocation status information.
In the event that it is determined that the OLRS has been compromised, one possible solution is to treat the CA as if it has also been compromised, even if it is known that the CA has not been compromised. There is no conventional way to revoke the CA's delegation certificate to the OLRS, because it is the OLRS that is relied upon for revoking certificates issued by the CA including the delegation certificate. If the CA is treated as if it has been compromised, in order to re-establish authentication system security it becomes necessary to (1) discontinue use of the current CA and OLRS, (2) begin using a new CA and OLRS, each of which have new respective private/public key pairs that are different from those used by the CA and OLRS that are no longer being used, (3) notify all other certificate authorities that previously issued certificates for the current CA's public key that such certificates should now be revoked, and (4) issue new certificates signed by the private key of the new CA that recertify principals' valid public keys that had been previously certified by the CA whose use is being discontinued.
The above-described conventional technique for re-establishing authentication system security involves needless consumption of significant amounts of administrative overhead to issue new certificates from the new CA to recertify principals' valid public keys. Thus, it would be desirable to provide an authentication system and process that are able to efficiently and securely re-establish authentication system security after compromise of an OLRS, but that do not require issuing of new certificates from a new CA to recertify previously certified, valid public keys.